This will throw a fit with anything below Erlang 17 though. I imagine the safer solution, at least until 18 is out, would be to just suppress the deprecation warnings, no?

/home/travis/build/Eonblast/Emysql/src/../include/emysql.hrl:39: referring to built-in type queue as a remote type; please take out the module name

The right solution is probably to branch off a development path and keep 'master' stable. There are so many things I want to do to emysql but the problem is I have to obey the old API. Having a branch-point with 17+ support could be a way to work around this.

Kinda feels like the forking problem that you worked so hard to reign in.
Though gods know this API could use a complete overhaul so I actually like
the sound of this.

A couple other thoughts here:

• Skip the typespecs altogether and leave them for docs
• Conditional compilation based on erlc library version (ugh)

The problem with ignoring the compilation warnings is that this problem is
exported via the hrl include, which you need to use this library. It
infects every module you use for database access. There are lots of
projects that require that warnings be treated as errors to make this an
actual problem, IMO.

On Wed, Oct 1, 2014 at 8:39 AM, Jesper Louis Andersen <
notifications@github.com> wrote:

The right solution is probably to branch off a development path and keep
'master' stable. There are so many things I want to do to emysql but the
problem is I have to obey the old API. Having a branch-point with 17+
support could be a way to work around this.

—
Reply to this email directly or view it on GitHub
#148 (comment).

How about this?choptastic@a80db4c

It works like the existing crypto_compat script and creates types emysql_dict, emysql_queue (using dict() for <17 and dict:dict() for 17+) which can then safely be pulled into apps and allows us to remove the "nowarn_deprecated" flag.

I briefly tested it with 17.3 and R16B.

Could work!